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The "vnc" URI Scheme 
Abstract 


Virtual Network Computing (VNC) software provides remote desktop 
functionality. This document describes a Uniform Resource Identifier 
(URI) scheme enabling the launch of VNC clients from other 
applications. The scheme specifies parameters useful in securely 
connecting clients with remote hosts. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This is a contribution to the RFC Series, independently of any other 
RFC stream. The RFC Editor has chosen to publish this document at 
its discretion and makes no statement about its value for 
implementation or deployment. Documents approved for publication by 
the RFC Editor are not a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7869. 


Copyright Notice 


Copyright (c) 2016 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. 
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1. Introduction 


Virtual Network Computing (VNC) clients are used to support remote 
desktop connectivity based on the Remote Framebuffer (RFB) Protocol 
[RFC6143]. It is often desirable to integrate such functionality 
with other software. However, the lack of a standard method for 
specifying VNC client parameters has limited such integration. 


The "vnc" Uniform Resource Identifier (URI) scheme specified in this 
document facilitates the launch of VNC clients from applications in 
browser-based, desktop, and mobile environments. Using this scheme, 
users and application vendors will be able to integrate remote 
desktop capabilities without being tied to a particular client. 


Remote desktop clients often store connection profiles in a local 
connection database. By associating connections specified in a URI 
with those stored in a database, client-specific options can be 
automatically applied to a connection launched from another 
application, even when that application is unaware of those options. 


Connections to VNC servers are often secured using mechanisms 
including Transport Layer Security / Secure Sockets Layer (TLS/SSL) 
tunneling [RFC5246] and Secure Shell (SSH) [RFC4251] tunneling, which 


are outside the scope of the RFB protocol. Defining the behavior of 
these client-integrated security options enables their use with "vnc" 
URIs. 

1.1. Requirements Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


In this document, these words will appear with that interpretation 
only when in ALL CAPS. Lowercase uses of these words are not to be 
interpreted as carrying the significance described in RFC 2119. 


2. The "vnc" URI Scheme 
2.1. URI Scheme Syntax 


The normative syntax of the "vnc" URI is defined in the <vnc-uri> 
rule in the following syntax specification. This specification uses 
the Augmented Backus-Naur Form (ABNF) as described in [RFC5234]. The 
"ync" URI conforms to the generic URI syntax specified in [RFC3986]. 
The <userinfo>, <host>, <port>, <unreserved>, and <pct-encoded> rules 
are defined in [RFC3986]. 
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vne-uri = "vnc://" [ userinfo "@" ] [ host [ ":" port ] ] 
[ "?" [ vne-params ] ] 
vnc-params = param "=" value *("&" param "=" value) ["&"] 
param = 1*( param-char ) 
value = *( param-char ) 


Lo 


Ta 


param-char 


unreserved / pct-encoded / unreserved-symbols 


LE S L 


= "e" vi "y" / 
/ ma" / myn 


wan / wom / won / 
/ "Min / Wow / Wes Mt 


unreserved-symbols 


The , and "&" characters 
and must be percent-encoded when 
specified in [RFC3986]. 
URI, 
not be percent-encoded when representing a data octet. 


Mowe are used to delimit VNC paramete 
representing a data octet as 


Within the <vnc-params> portion of a "vn 


A "vnc" URI has the general form: 
vnc://host:port?paraml=valueléparam2=value2... 

The host information and each parameter value specify information 
used in establishing or operating the remote desktop session as 
specified in Section 2.1.1. 


For example: 


vne://10.0.0.1:5901?VncPassword=secretéSecurityType=2 


rs 


ec" 


the <unreserved-symbols> do not have special meaning and need 


This example indicates a VNC connection to the host at IP "10.0.0.1" 
on port "5901" with VNC password "secret" using the VNC 
Authentication security type. 

1. URI Parameters 
A description of host information and URI parameters is provided in 


this section. 


Information on the constraints of various data types 


is provided in Section 2.1.2. 


All parameters are considered 


optional; however, a 
sufficient information. 


client will not be able to connect without 


A parameter without a specified default value indicates that no 


default value is implied by this URI scheme; 


however, 


VNC clients can 


apply implementation-dependent default behaviors otherwise consistent 


with this document. 
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The <userinfo> value is deprecated and processed only in an 
implementation-specific manner. The <userinfo> component MUST NOT be 
generated in an environment where a client supporting an updated URI 
format is expected to be available. When processing a URI value from 
an untrusted source, VNC clients SHOULD alert the user in order to 
mitigate the risk that the URI is constructed to obscure the identity 
of the remote host unless the URI can be validated or backwards- 
compatibility considerations make an alert impractical. 


The <host> and <port> values in the "vnc" URI specify the address of 
the VNC server on the remote host: 


Ho Ho +----------------------------- Ho + 
| Name | Type | Description | Default | 
Ho Ho HO o +---------- + 
| host | string | VNC server hostname or IP | none 

Ho Ho HO o Ho + 
| port | ushort | VNC server port | 5900 

Ho Ho +----------------------------- Ho + 


Warden & Iordanov Informational [Page 5] 


RFC 7869 The 


"vnc" URI Scheme 


May 2016 


The "vnc" URI parameter values specify remote desktop connection or 
session properties, including aspects of client operation, usability, 
and security as specified in the table below: 


Ho ooo Ho -- + 
| Name | Type | 
Ho ooo Ho o -- + 
|ConnectionName | string | 
+-------------—-— +--------- + 
| VncUsername | string | 
+-------------—-— +--------- + 
|VncPassword | string | 
Ho ooo Ho -- + 
| SecurityType | enum | 
| | <rfbsec> | 
Ho +--------- + 
|ChannelType | enum | 
| | <chan> | 
Ho ooo - Ho -- + 
| SshHost | string | 
Ho ooo Ho -- + 
|SshPort | ushort | 
Ho ooo Ho -- + 
| SshUsername | string | 
Ho ooo Ho -- + 
|SshPassword | string | 
Ho ooo Ho ooo + 
IdHashAlgorithm| enum 
<idhash> 
+-------------—-— +--------- + 
| IdHash | string | 
| | <hex> | 
Ho ooo Ho -- + 
ColorLevel enum 
<clevel> 
Ho ooo Ho -- + 
| ViewOnly | boolean | 
Ho ooo Ho -- + 


Hash algorithm used with 
"IdHash" parameter 


Expected hash of remote 
public key or certificate 


o ConnectionName, SaveConnection 


es + 
Default | 
aa a + 
none | 
=== + 
none | 
Sa ==s=s5e5 + 
none | 
== só + 
none | 
| 
ÓN + 
none | 
| 
=== 2 + 
<host> | 
aire tented sire + 
22 | 
== + 
none | 
A aa + 
none | 
e + 
none 
=== A + 
none | 
| 
=== + 
none 
=== + 
false | 
ÓN + 
none | 
ÓN + 


"ConnectionName" is used to identify a connection profile in both 


the launching application and VNC client. 
described in Section 2.2.2. 
port, 


name based on the host, 


client MAY normalize the name as required. 
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Profiles are applied as 
If omitted, the client MAY generate a 
and/or other parameters. 
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If true, "SaveConnection" indicates a connection profile should be 
created or updated and stored in the client connection database. 
If false, no profile should be updated or persisted. 


o VncUsername, VncPassword, SecurityType 


The "SecurityType" parameter indicates which RFB security type 
applies to the connection. RFB security types are recorded in the 
IANA "Remote Framebuffer Security Types" registry created by 
[RFC6143]. The VNC client will use this information to determine 
which parameters are required and establish the connection. 


VNC clients can sometimes automatically negotiate a security type 
with a server. Specifying the security type controls the security 
negotiation. Specifying the security type also allows a client to 
prompt for necessary security parameters prior to establishing a 
connection. Parameters may take time to enter on mobile clients 
and could otherwise result in timeouts and/or security lockouts. 
If the specified type is not supported by the server, an error 
SHOULD be indicated as described in Section 2.2.1. 


"VncUsername" and "VncPassword" are used when applicable to 
authenticate to the VNC server using the specified "SecurityType". 
Since passwords often contain arbitrary characters, they will 
often require percent encoding. 


o ChannelType 


"ChannelType" specifies the transport stream used to carry 
connection data. This allows a client to initiate a connection 
using a secure transport protocol such as SSH prior to connecting 
to the VNC server socket. Use of this value in the context of the 
"Integrated SSH" and "Secure Tunnel" channel types is provided in 
Section 2.3. 


o SshHost, SshPort, SshUsername, SshPassword 


The SSH parameters are intended for use with the "Integrated SSH" 
channel type described in Section 2.3.1. These parameters can 
also be used with any future SSH-based channel types. Since 
passwords often contain arbitrary characters, they will often 
require percent encoding. 
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o IdHashAlgorithm, IdHash 


The "IdHashAlgorithm" and "IdHash" values are used to verify the 
expected identity of the remote system based on its public key or 
certificate. Use of these values in the context of the 
"Integrated SSH" and "Secure Tunnel" channel types is provided in 
Section 2.3. 


o GColorlevel 


The "ColorLevel" parameter specifies the color model to use for 
data transfer and display as specified in Section 2.1.2. If the 
requested color model is unsupported, the behavior is 
implementation dependent. 


o ViewOnly 


If "ViewOnly" is true, the VNC client SHOULD operate in a display- 
only mode and refrain from sending input data including KeyEvent, 
PointerEvent, and ClientCutText messages specified in Section 7.5 
of [RFC6143] unless this mode is unsupported by the client. 


Parameter names SHOULD be provided in the case specified in this 
document; however, for compatibility, clients SHOULD accept 
parameters in a case-insensitive manner. Values SHALL be interpreted 
in a case-sensitive manner, unless otherwise noted. 


Additional parameters likely to be useful with multiple VNC clients 
can be added to the "VNC URI Parameters" registry as specified in 
Section 4.6 of this document. Individual clients MAY support 
parameters specific to that client. VNC clients supporting 
application-specific parameters SHOULD include a distinguishing 
prefix within the parameter name, such as the name of the application 
package specified in source code except when precluded by 
compatibility constraints. For example: 


vnc://?com.dell.vncclient.ScreenMode=28 


It can also be expected that clients will maintain backward 
compatibility with legacy URI formats and parameters. 


Legacy software applications respond to "vnc" URIs in different ways 


and may fail to behave as expected. It is advisable to test "vnc" 
URIs with specific applications or consult application-specific 
documentation. 
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2.1.2. Data Types 


"ync" URIs can be percent-encoded as specified in [RFC3986] and MUST 
be decoded. After decoding, the following type constraints and 
semantics apply: 


o string 


Values of "string" type are UTF-encoded strings as specified in 
[RFC3629]. 


The "string<hex>" subtype used in the "IdHash" consists of colon- 
delimited ":" octets displayed in hexadecimal. For example: 


5D:D2:39:57 


Comparison of "string<hex>" values SHALL be case insensitive; 
however, the uppercase notation is preferred for readability. 


o) enum 


The "enum" types consist of specific enumerated subtypes and are 
represented by their decimal value. 


The "enum<rfbsec>" values represent an RFB security type included 
in the IANA "Remote Framebuffer Security Types" registry created 
by [RFC6143]. 


"enum<chan>" values represent connection channel types listed in 
the "VNC URI Connection Channel Types" registry created by 


Section 4.4 of this document. Initial values are: 
Value Description 
T Standard TCP 
23 Secure Tunnel 
24 Integrated SSH 


The "Standard TCP" channel type represents a generic TCP 
connection. The "Secure Tunnel" and "Integrated SSH" [RFC4252] 
channel types are described in Section 2.3. 
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Values of the "enum<idhash>" parameter represent secure hash 
algorithms in the "VNC URI Hash Algorithms" registry created by 


Section 4.5 of this document. The initial values include: 
Value Description 
1 MD5 
2 SHA1 
4 SHA256 


The MD5 algorithm is described in [RFC1321]. The SHA-1 and 
SHA-256 algorithms are described in [SHS]. 


Values of the "enum<clevel>" subtype represent a color level. In 
the table below, the columns have the meaning specified in 
Section 7.4 of [RFC6143]: 


BPP = bits-per-pixel 
TC = true-color-flag 
RM = red-max 

GM = green-max 

BM = blue-max 

RS = red-shift 

GS = green-shift 

BS = blue-shift 


The values are: 


Value Description BPP Depth TC RM GM BM RS GS BS 

1 Black and White 8 3 oe i 1 1 2. 1-40 

2 Grayscale 8 6 E, 3 3 3 4 2 0 

3 8 Colors 8 3 En Ll 1 1 2 1 0 

4 64 Colors 8 6 E <3 3 3 4 2 0 

5 256 Colors 8 8 E Y 7 3 0 3 6 

6 16-bit Color 16 16 En BL 63 31 11 5 0 

7 24-bit Color 32 24 E 255° 255: 255 «1618 0 

8 30-bit Color 32 30 t 1023 1023 1023 0 10 20 
A value of "t" indicates the true-color-flag should be set. The 


big-endian-flag (see Section 7.4 of [RFC6143]) should be set as 
required for the system. 


o ushort 


The "ushort" values represent unsigned 16-bit integers expressed 
in decimal digits with value between 0-65535 inclusive. 
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o boolean 


"boolean" values represent conditions that are true or false and 
are represented as either "true" or "false" respectively. For 
maximum compatibility, clients SHOULD accept the value 1 as 
representing true values and 0 as representing false values. 
Clients SHOULD perform parsing of "boolean" values in a case- 
insensitive manner. 


An example "vnc" URI including several of these data types is: 


vne://localhost :5900?ConnectionName=ServeréSecurityType=2& 
TdHash=0D:3A:72:08:57:EA:4D: 30&SaveConnection=falseé& 


Note the above example should be considered to be a contiguous 
string without line breaks or whitespace and is broken into 
multiple lines in this document for readability. 


2.2. Processing URIs 


Conceptually, a "vnc" URI supports only a "VIEW" operation, 
indicating the user wishes to view the remote desktop accessible via 
the URI reference. 


In general, when a VNC client receives a "vnc" URI, it will initiate 
a remote desktop connection with the RFB protocol using the specified 
host information and parameter values. Initiating the connection 
using a connection channel mechanism such as those specified in 
Section 2.3 might require processing prior to establishing the RFB 
connection. A client MAY attempt to automatically discover or 
negotiate appropriate connection channel, security, or other 
parameter values. 


The process for negotiating security types is specified in [RFC6143]. 
Supported connection channels could be discovered by testing channel 

types to detect when a channel is successfully established. To best 

integrate with other applications, the VNC client SHOULD initiate the 
connection with minimal or no user intervention, whenever sufficient 

information is available and adequate security is preserved. 


Host information and parameter values may be provided through 
connection profiles. When a parameter value is not available from 
either a URI or a connection profile described in Section 2.2.2, the 
default value specified in Section 2.1.1 SHOULD be applied. If 
available parameters are not sufficient to establish a connection, 
the VNC client SHOULD present a session initiation data-entry screen. 
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2.2.1. Error Handling 


In a typical interactive environment, if an error prevents a session 
from being established, the VNC client presents an error message to 
the user. When the message is acknowledged, the console application 
can show a session initiation data-entry screen populated with 
available session parameters, or it can terminate. If an error 
occurs after a session is successfully established that terminates 
the connection, the VNC client presents a termination notification to 
the user. When the termination notification is acknowledged, the 
client can present a reconnection prompt or terminate. 


When an error occurs in a dedicated environment (such as a kiosk 
system), the system can transmit an alert to the remote operator, 
record a log entry, and execute appropriate fallback behavior such as 
automatically attempting to reestablish a session or displaying a 
generic message requesting servicing. 


2.2.2. Connection Profile Matching 


VNC clients MAY store remote desktop session settings in connection 
profiles. If the client is able to uniquely identify and associate a 
connection request with a connection profile based on the 
"ConnectionName" parameter value, remote host IP address, or hostname 
/ fully qualified domain name, the VNC client SHOULD apply profile 
values for those settings that do not have values supplied in the 
"vnc" URI. When profile data is unavailable, the VNC client MAY 
apply global application defaults for settings not supplied in the 
URI and for which the scheme does not specify a default value. The 
VNC client MUST NOT override supplied parameters with profile values 
or global defaults. 


When the "SaveConnection" parameter value is true, within the VNC 
client, a connection profile SHOULD be created or updated with the 
values supplied in the "vnc" URI. Profile updates and storage should 
be consistent with the recommendations in Section 3.4. 


2.3. Connection Channel Types 
2.3.1. The "Integrated SSH" Channel Type 


The "Integrated SSH" channel type establishes an SSH connection to a 
host, authenticates with SSH password authentication, establishes a 
secure tunnel to the VNC host/port, and then connects to the VNC 
server using a supported "SecurityType". The secure tunnel will 
provide encryption and data integrity, while verifying the public key 
authenticates the server. The SSH architecture is specified in 
[RFC4251]. The steps are detailed below: 
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1. The VNC client initiates a transport-level connection to the 
"SshHost" on the "SshPort" specified in the parameter values with 
a key exchange as described in [RFC4253]. 


2. When the VNC client receives the server key (or certificate), the 
hash of the key (or certificate) is computed using the algorithm 
corresponding to the "IdHashAlgorithm" parameter value and 
compared with the expected "IdHash" value (if available). If the 
certificate hash cannot be verified, the client alerts the user or 
operator. Ina typical interactive environment, the alert 
provides the remote system's identifying information including the 
hash value and allows the user to terminate the connection. The 
alert could allow the user to accept the key and continue 
establishing the connection. In a dedicated environment (such as 
a kiosk system), the system can transmit an alert to the remote 
operator, record a log entry, and execute appropriate fallback 
behavior such as displaying a generic message requesting 
servicing. 


3. The SSH client authenticates the user using the "SshUsername" and 
"SshPassword" parameter values according to the "password" 
authentication mechanism described in [RFC4252]. 


4. The SSH client opens a TCP/IP channel as specified in [RFC4254] 
from the local system to the system indicated by the <host> and 
<port> information values. 


5. The VNC client establishes an RFB connection to the VNC server 
over the channel and authenticates using the "SecurityType" as 
described in [RFC6143] or other reference. 


The VNC client MAY establish the connection described in this section 
using an external SSH client, by launching the client and then 
connecting to a secure tunnel created between a local port and the 
VNC server. 


If the VNC client is supplied with additional parameters outside the 
scope of this document, it MAY perform a variation of these steps 
consistent with the underlying protocols, for example, by using 
"publickey" SSH client authentication [RFC4252] or providing another 
form of authentication to the VNC server. The specific negotiation 
of SSH parameters such as cipher suite configuration is outside the 
scope of this document. 


Many SSH clients present key hashes using MD5, and it can be expected 


that launching applications will specify the hash be displayed in the 
manner its users are familiar with. 
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For compatibility, when the "SecurityType" parameter value is 
"Integrated SSH" (24), a VNC client MUST treat the value as a request 
to use "Integrated SSH" as the "ChannelType". However, this value 
SHOULD NOT be supplied for the "SecurityType" parameter unless 
required for backward compatibility as the channel is established 
prior to connecting to the server and is not consistent with the 
negotiation of other security types. 


2.3.2. The "Secure Tunnel" Channel Type 


The "Secure Tunnel" channel type establishes a TLS connection with a 
remote server using certificate authentication, over which a 
connection to the VNC server is established using a supported 
"SecurityType". The secure tunnel will provide encryption and data 
integrity, while verifying the certificate authenticates the server. 
The TLS protocol is specified in [RFC5246]. The steps are detailed 
below: 


1. The VNC client initiates the TLS Handshake Protocol with a system 
indicated by the <host> and <port> information values. 


2. When the server certificate is received, the hash of the key 
certificate is computed using the algorithm corresponding to the 
"IdHashAlgorithm" parameter value and compared with the expected 
"IdHash" value (if available). If the certificate hash cannot be 
verified, the client alerts the user or operator. Ina typical 
interactive environment, the alert provides the remote system’s 
identifying information and allows the user to terminate the 
connection. The alert could allow the user to accept the key and 
continue establishing the connection. In a dedicated environment 
(such as a kiosk system), the system can transmit an alert to the 
remote operator, record a log entry, and execute appropriate 
fallback behavior such as displaying a generic message requesting 
servicing. 


When providing identifying information of a host identified by an 
X.509 certificate [RFC5280] [X.509], the certificate subject, 
issuer, validity period, and certificate hash is typically 
included. The VNC client MAY verify the validity of the 
certificate. If the validity of a certificate is not confirmed, 
the alert includes a statement indicating such information has not 
been verified. 


3. The client finishes establishing the TLS tunnel. 
4. The VNC client establishes an RFB connection to the VNC server 


over the channel and authenticates using the "SecurityType" as 
described in [RFC6143] or other reference. 
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If the VNC client is supplied with additional parameters, it MAY 
perform a variation of these steps consistent with the underlying 
protocols, for example, by providing another form of authentication 
to the VNC server. The negotiation of specific TLS parameters such 
as cipher suite configuration is outside the scope of this document. 


The TLS protocol provides backwards compatibility with SSLv3; 
however, due to known security flaws, it SHOULD NOT be used. 


For compatibility, when the "SecurityType" parameter value is "Secure 
Tunnel" (23), a VNC client MUST treat the value as a request to use 
"Secure Tunnel" as the "ChannelType". However, this value SHOULD NOT 
be supplied for the "SecurityType" parameter unless required for 
backward compatibility as the channel must be established prior to 
connecting to the server and is not consistent with the negotiation 
of other security types. 


3. Security Considerations 


General security concerns involving URI schemes are discussed in 
[RFC3986]. In implementing support for the "vnc" URI scheme, areas 
for particular consideration include application trust, URI handling, 
host identification, and connection database security. 


Remote desktop connectivity requires the transmission of security 
credentials, which could be included in a URI. If those credentials 
are not kept secure, an attacker can gain access to any systems using 
those credentials. Host addresses and connection parameters might 
also be considered sensitive, as such information can be used in 
planning an attack. 


URIs can also contain host identification information. It is 
important to securely identify the remote host system to which a 
connection is established. If a user connects to an attacker’s 
system, user data, including credentials, can be exposed. 


Note that the RFB protocol itself may not encrypt data. To protect 
data in transit, RFB should be tunneled over TLS [RFC5246], SSH 
[RFC4251], or another secure protocol. 


Some VNC systems can be used without authentication. To protect the 
remote host, strong passwords or other authentication mechanisms need 
to be used. 
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3.1. Application Trust 


A malicious application receiving VNC credentials via URI or other 
means can obviously misuse those credentials. To protect against 
this, users should only install applications from trusted sources. 
The integrity of application packages can be verified through digital 
signatures. 


Applications launching VNC clients can elect to launch only 
particular trusted clients and can specify those clients through 
platform-specific mechanisms. Package integrity can be verified 
programmatically by querying the package manager for digital 
signatures or other platform-specific means. 


The risk to a VNC client from a launching application is generally 
much lower, since the launching application will not receive 
credentials or data from the client. A VNC client can verify its 
caller thorough platform-specific means. 


VNC clients ought not to accept potentially destructive parameters 
from untrusted launching applications without explicit user 
confirmation. For example, a client-specific parameter that runs an 
arbitrary command upon establishing an SSH connection used for VNC 
tunneling is potentially destructive and high risk. 


3.2. URI Handling 


Within a mobile or desktop environment, application launch will 
typically involve in-memory URI data transmission facilitated and 
secured by the operating system. 


When "vnc" URIS are exchanged or used within a system, their contents 
might be exposed by process listings or other instrumentation. Users 
need to avoid including sensitive information in "vnc" URIs that 
could be exposed to unauthorized observation. 


If sensitive URI information is exchanged across a network, for 
example, by providing a list of connection URIs in a web page, the 
data needs to be encrypted in transit and only be accessible to 
authorized users. 


When an application detects potentially sensitive information ina 
"ync" URI, it needs to be handled securely or discarded. In 
particular, URI data on persistent storage needs to be encrypted as 
described in Section 3.4. 
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Since "vnc" URIs may contain sensitive information, applications 
should avoid logging the URIs even when errors occur. Users need to 
avoid including sensitive information in "vnc" URIs that are used 
with applications where logging is unavoidable. 


Applications that process URIs in a generic way, such as web 
browsers, might not detect that sensitive information is contained in 
a URI and could cache or store that information insecurely. It is 
advisable to avoid including credentials and other sensitive 
information in URIs that are likely to be processed in a generic way 
unless such caching and storage is disabled or otherwise secured. 


3.3. Host Identification 


In the absence of verifiable host identification, a VNC client 
application is vulnerable to spoofing and man-in-the-middle attacks 
that capture VNC or host OS credentials and user data. To prevent 
such attacks, administrators SHOULD secure their VNC communications 
with TLS [RFC5246] or SSH [RFC4251] tunnels or other connection 
mechanisms identifying remote hosts via certificate or public key. 
VNC clients MUST verify the respective certificates or public keys to 
confirm the remote host’s identity. 


An application launching a VNC client via URI MAY provide a 
certificate hash or public key hash identifying the remote host. VNC 
clients maintaining a connection database can also store certificate 
or public key data suitable for validating a host’s identity. 


If connecting to a system identified by certificate or public key and 
a remote system ID hash cannot be matched to available identifying 
data, the VNC client needs to alert the user or operator. Ina 
typical interactive environment, the alert will provide the remote 
system’s identifying information and allow the user to terminate the 
connection. The alert can allow the user to accept the information 
and continue establishing the connection. In a dedicated environment 
(such as a kiosk system), the system can transmit an alert to the 
remote operator, record a log entry, and execute appropriate fallback 
behavior such as displaying a generic message requesting servicing. 


When providing identifying information of a host identified by an 
X.509 certificate [RFC5280] [X.509], the certificate subject, issuer, 
validity period, and certificate hash need to be included. The VNC 
client can verify the certificate validity. If the validity of a 
certificate is not determined, the alert needs to include a statement 
indicating such information has not been verified. 
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Identifying information of a host identified by public key, such as 
the endpoint of an SSH connection using a raw key, needs to include a 
hash of the key. 


3.4. Connection Database Integrity 


A VNC client application and/or launching application can maintain a 
connection database containing remote host information, credentials, 
and/or connection parameters. Applications storing credentials need 
to ensure they are stored in an encrypted format with a decryption 
process requiring user-supplied or device-specific data. If 
supported, it is advisable for applications to have a setting 
disabling storage of credentials. 


If available, the VNC client connection database can store 
certificate or public key data used to verify host identification. 

To prevent a malicious URI from overriding the database, if 
identification information in the URI conflicts with information in 
the database, the user or operator needs to be alerted. In a typical 
interactive environment, the user can be prompted to accept the new 
information prior to updating the database. 


4. IANA Considerations 


The "vnc" scheme has been registered in the "Uniform Resource 
Identifier (URI) Schemes" registry. 


The "Remote Framebuffer Security Types", "VNC URI Connection Channel 
Types", "VNC URI ID Hash Algorithms", and "VNC URI Parameters" 
registries support elements of the scheme. 


4.1. "vnc" Scheme 


IANA has added the "vnc" scheme to the "Uniform Resource Identifier 
(URI) Schemes" registry with description "Remote Framebuffer 
Protocol" and reference to this document. A registration template is 
provided in Appendix A. 


The IANA schemes registry is currently located at 
<http://www.iana.org/assignments/uri-schemes>. 


4.2. Remote Framebuffer Security Types 
This document references the existing IANA "Remote Framebuffer 


Security Types" registry in specifying security type options. RFB 
security types are supported in "vnc" URIs. 
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Security mechanisms integrated with VNC clients might need to alter 
the process by which a connection is established prior to the 
security handshake described in Section 7.1.2 of [RFC6143]. Such 
mechanisms should be reflected in the "VNC URI Connection Channel 
Types" registry described in Section 4.4 of this document rather than 
the "Remote Framebuffer Security Types" registry, as their use cannot 
be negotiated by the mechanism specified in [RFC6143]. 


Exceptions can be made for backwards compatibility. IANA has updated 
the "Secure Tunnel" and "Integrated SSH" security types to refer to 
this document. 


4.3. VNC URI Group 
IANA has created a "Virtual Network Computing (VNC) Uniform Resource 
Identifier (URI)" group. This group contains application-level, URI- 
related registries distinct from those used by the RFB protocol 
itself. 

4.4. VNC URI Connection Channel Types 


IANA has created a "VNC URI Connection Channel Types" registry within 
the "Virtual Network Computing (VNC) Uniform Resource Identifier 


(URI)" group. The registry includes Value, Description, and 
Reference columns. The initial contents of the registry are 
described in this document. The values of the "Secure Tunnel" and 


"Integrated SSH" types are copied from the RFB Security Types 
registry. They are: 


Value Description Reference 

0 Reserved this document 
1 Standard TCP this document 
23 Secure Tunnel this document 
24 Integrated SSH this document 


The maximum acceptable value is 2,147,483, 647. 


Future assignments to this registry should be made through the "First 
Come First Served" process described in [RFC5226]. 


4.5. VNC URI ID Hash Algorithms 
IANA has created a "VNC URI ID Hash Algorithms" registry within the 
"Virtual Network Computing (VNC) Uniform Resource Identifier (URI)" 


group. The registry includes Value, Description, and Reference 
columns. 
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The initial hash algorithms specified are a subset of the algorithms 
contained in the "TLS HashAlgorithm Registry". The initial contents 
of the registry are: 


Value Description Reference 

0 Reserved this document 
1 MD5 this document 
2 SHA1 this document 
4 SHA256 this document 


The maximum acceptable value is 2,147,483, 647. 


Future assignments to this registry should be made through the "First 
Come First Served" process described in [RFC5226]. 
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IANA has created a "VNC URI Parameters" registry within the "VNC URI" 


group. 
The initial contents are described in this document. They are: 

PE E ST E E E S + 
| Name Description Reference 
a Sn A + 
| ConnectionName Name of connection profile this document | 
saan ST A + 
| VncUsername VNC server username this document 

saan Se e + 
| VncPassword VNC server password this document 

AA SE E A A + 
| SecurityType RFB security type used this document | 
o a ii id da + 
| ChannelType Connection channel type this document | 
HeSSS Ss SSS SS SSS sa SSS SSS SS SS So Se SS Se Sh a SS SS Se + 
| SshHost SSH server hostname or IP this document | 
A Sn a E A I E T E + 
| SshPort SSH server port this document | 
phia He a a + 
| SshUsername SSH username this document | 
prennan e a ha a e e a + 
| SshPassword SSH password this document | 
a a a a Se ee + 
| IdHashAlgorithm Hash algorithm used with this document | 
| "IdHash" parameter | 
D E ci + 
| IdHash Expected hash of remote this document | 
| public key or certificate 

UAS E a A N E N E A + 
| ColorLevel Client color depth/mode this document | 
O A A E + 
| ViewOnly Client is view only this document 

N L SAE A AT + 
| SaveConnection Store connection info this document 

a a a + 


Future assignments to this registry should be made through the "First 
Come First Served" process described in [RFC5226]. 
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Appendix A. "vnc" URI Template 
This template is provided for registration of the "vnc" URI in the 
IANA "Uniform Resource Identifier (URI) Schemes" registry as 
specified in [RFC7595]. 
Scheme name: vnc 
Status: Permanent 
Applications/protocols that use this scheme name: Virtual Network 


Computing (VNC) remote desktop applications use vnc URIs. VNC 
applications use the Remote Framebuffer (RFB) protocol. 


Contact: IESG <iesg@ietf.org>. 


Change Controller: See the authors of this document. Change control 
is through the IESG on behalf of the IETF <iesg@ietf.org>. 


References: This document. 
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